Smart cards are wallet-size or smaller devices with embedded integrated circuits. A smart card typically comprises a processor and memory. Smart cards come with various tamper-resistant properties and are capable of storing vital information and hosting sensitive applications in a secure manner. Smart cards implementing Java Card technology further enhance application security by executing applications in different firewalls, or execution contexts. Under this enhanced security scheme, data, methods and/or objects inside a server application can only be accessed through shareable interface objects (SIO's) by a client application executing in a different execution context.
In order to obtain a SIO from a server application, a client application uses a multi-step procedure. First, the client application is required to have specific knowledge of an application identifier for the SIO and prepare a binary representation of that application identifier. Second, the client application is required to invoke a first system call “JCSystem.lookupAID( )” with the binary representation prepared. Third, the system returns a corresponding application identifier object to the client application if the application identifier is determined as genuine. Fourth, the client application is required to invoke a second system call “JCSystem.getAppletShareableInterfaceObject( )” and pass the returned application identifier object in the call. Fifth, the system in turn invokes a method supplied by the server application, “Applet.getShareableInterfaceObject( )” to obtain the SIO. The server application may implement logic in the aforementioned method to either allow or deny access to the SIO by the client application. If the access is allowed, the SIO is passed from the server application to the client application via the system.
One disadvantage of these techniques is that a client application is forced to have specific knowledge of an application identifier for a SIO in a server application. This specific knowledge must be hard-coded in the client application at development time. Thus, if the hard-coded application identifier does not correctly match with an intended SIO, the client application is likely to face serious problems in its execution at runtime.
Another disadvantage of these techniques is that they cannot easily accommodate web applications such as servlets that provide web-based service, or access, to data, methods and/or objects in the web applications. A web-based service can be identified by a Unified Resource Identifier (URI), which is of variable lengths from several bytes to more than several hundred bytes. An application identifier, on the other hand, has a fixed length of sixteen bytes comprising five bytes that identifies a specific vendor and eleven bytes that the vendor can use for its own purpose. Since a URI is frequently much longer than sixteen bytes, the URI cannot simply be accommodated using an application identifier scheme. Thus, web-based services cannot be exposed to client applications in different execution contexts through SIOs that are identified only by application identifiers under the legacy operating model.
Because of these limitations, the existing techniques are not as useful in enabling an application executing in one execution context in a smart card system to access data, methods and objects of another application executing in a different execution context through a shareable interface object, as would be desired. As a result, an improved mechanism which would enable such access between applications is needed.